Just a few years ago, it was normal to configure network apparatuses using proprietary interfaces, differing across vendors, apparatus types (switches, routers, firewalls, load balancers, etc.), and even different firmware releases for a same apparatus. Managing heterogeneous multivendor networks of non-marginal scale was (and still is) extremely difficult, and required (and still requires) a huge expertise.
“OpenFlow” emerged quite recently, i.e. in 2008, as an attempt to change this situation. OpenFlow's breakthrough was the identification of a vendor-agnostic programming abstraction for configuring the forwarding behavior of network switching apparatus. Via the OpenFlow Application Programming Interface, in short “API”, network administrators can remotely reconfigure at runtime forwarding tables, probe for flow statistics, and redirect packets not matching any local flow entry towards a network controller for further analysis/processing and for taking relevant decisions; in essence “program” the network from a central control point, clearly separated from the forwarding level.
Today, such vision is called Software Defined Networking, in short “SDN”.
OpenFlow turned to be immediately deployable, thanks to its pragmatic balance between open network programmability and real world vendors' and deployers' needs. Starting from the recognition that several different network devices implement somewhat similar flow tables for a broad range of networking functionalities (L2/L3 forwarding, firewall, NAT, etc.), the authors of OpenFlow proposed an abstract model of a programmable flow table which was amenable to high-performance and low-cost implementations; capable of supporting a broad range of research; and consistent with vendors' need for closed platforms.
Via the OpenFlow “match/action” abstraction, the device programmer can broadly specify a flow via an header matching rule, associate forwarding/processing actions to the matching packets, and access bytes/packet statistics associated to the specified flow.
Some years have now passed since the OpenFlow inception, and the latest OpenFlow standard, now at version 1.5, appears way more complex than the initial elegant and simple concept. To fit the real-world needs, a huge number of extension (not only the initially foreseen functional ones, such as supplementary actions or more flexible header matching, but also structural ones such as action bundles, multiple pipelined tables, synchronized tables, and many more) were promoted in the course of the standardization process. And new extensions are currently under discussion for the next OpenFlow version.
All this hectic work was not accompanied by any substantial rethinking in the original programmatic abstraction (besides the abandoned Google OpenFlow 2.0 proposal, considered too ambitious and futuristic), so as to properly capture the emerging extensions, simplify their handling, and prevent the emergence of brittle, platform-specific, implementations which may ultimately threaten the original vendor-independency goal of the OpenFlow inventors.
Even if an OpenFlow apparatus may now be rich of functionalities and primitives, it remains completely “dumb”, with all the “smartness” placed at the central network controller side.
From the article “Simpler Network Configuration with State-based Network Policies” by H. Kim et al. of the Georgia Institute of Technology, College of Computing SCS technical report, there is know a solution based on OpenFlow; according to this solution, the network forwarding apparatuses (see switches in FIG. 1) are traditional OpenFlow switches, i.e. “dumb”, and all the “smartness” is placed inside a central network controller called “PyResonance controller” (see upper part of FIG. 1 and corresponding explanation in paragraph 2.1). The network forwarding apparatuses (that may be called simply “apparatuses”) according to this solution comprises, as always, an internal data packets handling circuitry and an internal apparatus controller. The “smartness” is implemented inside the central network controller using a programming abstraction based on traditional Finite State Machines, in short “FSM”.
Recently and despite OpenFlow's data plane programmability, the need to use advanced packet handling for important network services has lead to the proliferation of many types of specialized “middle-boxes”. The extension of programmability and exibility features to these advanced network functions is a crucial aspect, and a recent trend is that of virtualizing them in data centers on general purpose hardware platforms and to make them programmable and configurable using SDN approaches.
The present Inventors wanted to follow the OpenFlow approach (avoiding “middle-boxes” and “virtualization”), i.e. network management control should be (logically) centralized; in other words, they wanted to keep the control plane and the data plane separate according to the spirit of SDN.
However, the present Inventors posit that several statefull tasks, just involving local states inside single links/switches are unnecessarily centralized according to OpenFlow and not deployed to the local apparatuses. As a result, the explicit involvement of the controller for any statefull processing and for any update of the match/action rules, is problematic. In the best case, this leads to extra signaling load and processing delay, and calls for a capillary distributed implementation of the “logically” centralized controller. In the worst case, the very slow control plane operation a priori prevents the support of network control algorithms which require prompt, real time, reconfiguration in the data plane forwarding behavior.
In essence, dumbness in the data forwarding plane appears to be a by-product of the limited capability of the OpenFlow data plane API—Application Programming Interface, rather than an actual design choice or an SDN postulate.
Therefore, the present Inventors thought of a better data plane API—Application Programming Interface which would permit to program some level of smartness directly inside the forwarding apparatuses.
The present Inventors thought that a major shortcoming of OpenFlow is its inability to permit the programmer to deploy states inside the forwarding apparatus.
However, adding states to OpenFlow was considered not sufficient: the programmer should be entitled to formally specify how states should be handled, and this specification should be executed inside the apparatus with no further interaction with the controller.
Furthermore, they considered that an effective solution should have come along with two attributes: (1) be amenable to high speed implementation, (2) not violate the vendor-agnostic principle which has driven the OpenFlow invention, and which has fostered SDN; in essence, an effective solution should be a concrete and pragmatic “abstraction”, rather than a theoretical approach.
The present inventors proposed a viable abstraction to formally describe a desired statefull processing of flows inside the network forwarding apparatus, without requiring the apparatus to be open source or to expose its internal design. Such abstraction relies on Finite State Machines, in short “FSM”, in particular eXtended Finite State Machines, in short “XFSM”.
Extending the OpenFlow abstraction through the use of FSM, in particular XFSM, allows to offload on high performance switches a pretty large set of functions reducing the need to rely on controllers and middle-boxes.
According to the present invention, inclusion of flow states is not limited to the functionality of the apparatus, i.e. its packets handling capabilities, but it takes into account the API—Application Programming Interface.
Advantageously, extending the OpenFlow abstraction through the use of FSM is not disruptive, i.e. it is in line with traditional OpenFlow, and therefore it would be relatively easy to be introduced into existing networks and used by current network operators.
The present Inventors are aware that XFSMs have already been proposed in the field of network apparatuses; anyway, this was done for a completely different application, i.e. in order to convey a desired medium access control operation into a wireless interface card; therefore, the old application and the new application are not related and comparable.
A solution quite similar to the solution of the present invention is known from international patent application published as WO 2015/136432 A1 (from the same inventors) which is incorporated herein by reference. Such solution is based on a state table and a flow table both located inside the network forwarding apparatus; the state table stores data relating to the current state of all data packet flows, and the flow table stores data relating to information for updating the content of the state table and information for causing actions on the received data packets.